1.1 Overview
This document will provide an overview of the system as a whole, listing architectural drivers and other requirements that have driven its design. Multiple architectural views will be included to further describe the system and its goals. An architectural view provides information on how different parts of the system handle issues that might arise during development and after deployment, such as how to handle concurrency in a system.
Architectural Drivers are the motivations that influence and direct the project toward the end result. They specifically provide areas that the system has targeted from a non-functional aspect to address, such as usability or reliability. This section contains three drivers that were identified for this project: Usability, Low Coupling, and Reliability. The discussion of each driver shall contain a description of its importance to the project and a strategy that will be used to reflect them in the system architecture.
There are several other architectural drivers that could have been used for this system, such as Performance, and Availability; however, they do not have as much of an impact on the system as the ones identified below. In future iterations of this system, such drivers as performance could be looked into especially if a desktop application user interface is used instead of the web based interface that is reflected in this architecture document and the design document. Since this will initially be designed and implemented as a web application, performance is not a major driver due to the nature of using the internet or private network as a data medium. Performance however could be reflected if this application is modified to a non-web application.
Availability is also a driver that could be looked at in future revisions; however, this again by the nature of being web-based is not as much a priority as the other drivers listed below. Reliability would be considered more important that availability. Since the system will rely on SVN as a form of persistence, it will be more important to handle the situation when the SVN server is temporarily unavailable. Because the system shall be designed to be fault tolerant, availability is almost implied and therefore not needed as an additional driver.
2.1 Usability
2.1.1 Importance
Currently PAETEC uses ad hoc processes and methods to manage their product catalogs. This can lead to confusion as to how products are defined. Since some of the users will be non-IT users, it is important that this system’s interface allows users to quickly and easily understand how products and product catalogs are defined.
2.1.2 Strategy
This project will provide PAETEC with a tool capable of defining all their products and an interface that allows them to manage these definitions. Allowing users to specify all products with a consistent interface will greatly improve PAETEC’s product catalog definition process. The system’s interface will be designed to be intuitive and descriptive to support users during any task. The system will be designed to show as much information about a product as possible, without overwhelming the user.
2.2 Low Coupling
2.2.1 Importance
The stakeholders of this project requested that the user interface be separate from the rest of the system. This way it may easily be replaced at a later date if desired.
2.2.2 Strategy
The system will be designed using the Model View Presenter pattern. This will require the user interface to manipulate the model by using indirect access methods. The selection of GWT was made because of its support for the MVP pattern, which helped reinforce the patterns use within the architecture.
2.3 Reliability
2.3.1 Importance
It is important for this system to be fault tolerant, as it is very important that if an error occurs that the system process will not fail or corrupt any of the data that is contained within the system. Such an example of an error could be SVN going down. If this were to occur it would be bad to shut the system down, or prevent the user(s) from making changes to the model.
2.3.2 Strategy
The system shall be designed in such a manner that allows for the system to continue operation even in the occurrence of such an error like SVN going down. SVN would be the most likely occurrence of an external dependency failing and causing an impact on the way the product catalog system operates. To mitigate this from affecting the system, as long as a user is authenticated in the system, then they will be able to lock, and make changes to the system representation of the model. Although they will not be able to save into SVN, once SVN is restored the server will check-in any changes that were made when the system goes down. For more information on SVN and how it interacts with the Product Catalog Editor system, please refer to section 3.2.
3.1 Model View Presenter
3.1.1 Description
Model View Presenter is a pattern based on Model View Controller. The system contains three components, the Model, the View, and the Presenter. This pattern enforces a separation between UI elements and logic. The view will contain UI elements. The Model is where data is kept and changed. The Presenter acts as a median between the View and the Model. When the model is updated, the view needs to be updated as well. The Presenter updates the view to reflect changes in the model. Only the presenter handles interactions with the model. The view is unaware of any changes made in the model. Whenever an event is triggered in the View, they will invoke a method in the presenter.
3.1.2 Diagram
3.1.3 Reasons
The pattern allows for a separation of logic and core functionality from the User Interface level and the clear structure of the architecture makes the code easier to maintain. This will also increase the ease of replacing interface components, or even the whole user interface. An added bonus by using this pattern with Google Web Tool (GWT) is that the GWT framework supports this pattern and provides a way to make the user interface easier to test, due to the entire separation of the UI from the rest of the system.
3.1.4 Discussion of Pattern Being Retired
In 1996, Martin Fowler claimed that this pattern should be retired, as he felt that the pattern did not reflect the nature of the industry any more. He took the pattern and split into two new patterns, the Passive View and the Supervising Controller. Our representation of the model view presenter is not the basic design of this type of pattern, rather it is closer to the Passive View pattern described by Fowler; however, we still call it Model View Presenter because it tends to follow the Microsoft revision of the MVP pattern. Basically there are two names for this pattern; one, the MVP and the other the Passive View, and other than the name differences they are essentially the same pattern. Although Fowler retired the pattern, GWT can be used with a Model View Presenter or Model View Controller based pattern and for this project the MVP pattern was determined to be the best route, as it would provide the most flexibility from a user interface standpoint, since the UI should be lightweight to allow for it to be replaced in the future if needed.
3.2 Subversion Tactic
3.2.1 Description
Subversion (SVN) shall be used as the underlying data containment structure for the product catalog editor. The SVN repository shall contain a file for each product that will consist of the product's information and the entities that the product contains with their corresponding contents. The files in the repository however shall be read in all at the same time providing a model of the entire system. The model shall update the files in the repository when a user submits a change to the model. This method shall limit the transactions made to the SVN repository and will increase system response time and interaction with the user by providing quick request and locking of the model.
The system shall implement a locking mechanism on both an object within the system and within SVN. The locking shall occur at the product entity level, and by doing it will solve the concurrency issue with multiple users who wish to work on entities within the product. By locking at the product level, a product and all its entities shall not be able to be used by anyone else using the system. This includes even viewing the product. When the user releases the lock, if changes were made to the system representation, then the master definition located within SVN shall be updated.
3.2.2 Fault and Error Handling
Issues could arise if something causes the SVN server to go down, as we would not want a user to lose information that they tried to commit during his or her session. This will be handled through a confirmation of the commit whenever the user saves the changes made to the model. This will be talked about more in depth within the design document, but the model itself will retain any changes that are made in the system, therefore it would be possible to recommit once SVN comes back up.
3.2.3 Rejected Alternatives
3.2.3.1
Description
Each entity will be contained in a separate file. The system will check out files and send the information to the client whenever that entity is viewed. When a user elects to edit a particular entity, the system will lock that file. When the user is finished making changes, the system will check the file in and release the lock.
3.2.3.2
Faults
Having each entity and a separate file may cause too great a strain on SVN. Also, PAETEC has expressed that they would like a product to lock as soon as it is viewed. If this is the case then the entire definition for a product should be contained in one file.
3.3 Client-Server
3.3.1 Description
When creating a web application a natural client-server framework exists in which the system is distributed between different systems. One system lives in the client’s web browser providing a user interface for the user to interact with the server on the other side. The other system lives on a remote server, allowing for all business logic to operate away from the client. The separation of modules onto different machines is the definition of a distributed system and they can contain many different forms. In this case there exists a four-tiered structure of the system, the Presentation layer, the Web layer, Application layer and the persistence layer. In this system the Presentation layer as mentioned before will be a represented by a thin client, allowing for the UI to be changed without affecting the underlying functionality of the system. The web layer is represented by the application server, Tomcat, and GWT RPC to make the remote calls to the server. The Application layer will be the core of the system that maintains an internal model of product catalogs, read/writes information to/from SVN, and performs application business logic. The Persistence layer will be implemented using SVN as a data containment structure.
3.3.2 Diagram
3.3.3 Reasons
The GWT framework structure is based upon a model-view-presenter client-server architecture that allows for a separation between the core functionality and the user interface. GWT provides this separation by utilizing a remote method invocation known as GWT RPC. GWT also easily integrates with Tomcat Application server by allowing for the developers to create UIs with Java Swing type code and then generating JSP files during compile time, thus simplifying web application development.
4.1 Deployment View
4.1.1 Background
This view represents the deployment of the system. This diagram depicts a static overview of the run-time configuration of the hardware, the software installed on the hardware, and the middleware used to connect the distinct machines to one another.
4.1.2 Diagram
4.1.3 Elements
Web Browser: The Application that the user uses to interact with the system.
Client View: The view that the user sees and interacts with.
GWT RPC Client Side: Handles all remote transactions with the server.
Tomcat: Completes requests that it receives from each client and processes the request.
GWT RPC Server Side: Handles all remote transactions with the user
Application Logic: Manages all entities within the product hierarchy and completes client request.
JavaSVN Connector: Handles getting files to and from SVN.
SVN: where the files for the elements of the product catalogs are saved.
4.1.4 View and UI Description
The reference of a Client View subsystem is nothing more than a high level concept for what the user will see for a user interface inside the web browser of their choice. The Client View is considered the View portion of the MVP pattern chosen for the system and exists with the intent that it could be replaced at any time with a different form of user interface. To change the interface, it would be as simple as creating a new UI and then connecting it to the Application Logic component of the system. The Client View only knows about what it is showing for a screen and does not know about the object hierarchy that exists inside the Application Logic component, which provides this level of flexibility, and abstraction for the UI.
4.1.5 Deployment Requirements
- SVN
- Java
- Tomcat
4.2 Concurrency View
4.2.1 Background
This view represents the possible scenario in which multiple users are concurrently querying the server to perform some action that will then be processed inside it, either by retrieving data or by calculating or modeling an element inside the server. Although it is highly unlikely that there would ever be the scenario where multiple users were actually editing the same element at the same time, the system shall actually implement a locking mechanism that forces the user to lock an element that is being edited in the system to prevent data corruption. This locking shall occur at the product level, meaning that if a user is editing any entity within a particular product, no other user can view or edit any other entity within that product or the product itself until the other user has released the lock.
4.2.2 Diagram
4.2.3 Elements
User 1-4: Clients using the system at the same time and requesting a request that will be processed at the same time on the server.
User Interface: Interface that is commonly used for each user.
Server: Completes requests that it receives from each client and processes the request.
SVN: where the files for each element in the product catalog hierarchy is saved. Each element stored in SVN could theoretically be accessed simultaneously by multiple clients and therefore should be carefully watched by the system to make sure that no issues arise with one user viewing and another user editing.
4.3 Distributed View
4.3.1 Background
This view represents the distributed nature of the Product Catalog Editor. Although it is only run via a single server the structure of the system would allow for it to be separated onto multiple servers. A web application by nature is distributed in the fact that it separates the client and logic onto different machines, more specifically the client UI lives on the user’s machine, typically and in this case the web browser. The logic related to the system and the system model all live on a remote machine that the client UI interacts with to perform requests and tasks in the system. Although this is similar to the Deployment View, this view provides a little more detail as to how the subsystem structure shall be architected and what it will look like from a higher level abstracted away from detailed design, yet more detailed than from just a deployment standpoint.
4.3.2 Diagram
4.3.3 Elements
Client UI: This is the sub-system that exists on the client end.
Dispatcher: This is the sub-system that exists on the server that handles all requests issued by the Client using GWT RPC.
Application Logic: This is the sub-system also located on the server that handles model creation and queries the database for information regarding the model.
SVN: This is the sub-system that interacts with SVN and allowing for exporting of the model to a specified format.